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(54) Secure interaction between downloaded application code and a smart card in a mobile 
communication apparatus 



(57) A method for controliingthe access to a security 
token (CAR) in a communication apparatus (ME) by 
downloaded applications (DA) accessing the security 
token, characterized in that it comprises the following 
steps: 

a. A service-accessing step in which a downloaded 
application (DA) requests an access to the security 
token (CAR), 



b. A service-checking step in which a security token 
manager (STM), stored in the communication ap- 
paratus, checks the corresponding rights, 

c. And in that, the communication apparatus storing 
a plurality of security token interfaces (STI), the Se- 
curity Token Manager (STM)delivers the demanded 
Security Token Interface (STI) to the application 
(DA) if rights are satisfied or reject the demand . 
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Description 

What is the field of the invention? 

[0001 ] Many cryptographic tokens such as Integrated 
Circuit Cards (IC cards or 'smart cards') are intrinsically 
secure computing platforms ideally suited to providing 
enhanced security and privacy functionality to applica- 
tions. They can handle authentication information such 
as digital certificates and capabilities, authorizations 
and cryptographic keys. Furthermore, they are capable 
of providing secure storage and computational facilities 
for sensitive information such as: 

• Private keys and key fragments. 

• Account numbers and stored value. 

• Passwords and shared secrets. 

• Authorizations and permissions. 

[0002] At the same time, many of these tokens pro- 
vides an isolated processing facility capable of using this 
information without exposing it within the host environ- 
ment where it is at potential risk from hostile code (vi- 
ruses, Trojan horses, and so on). This becomes critically 
important for certain operations such as: 

• Generation of digital signatures, using private keys, 
for personal identification. 

• Network authentication based on shared secrets. 

• Maintenance of electronic representations of value. 

• Portable permissions for use in off-line situations. 

[0003] New mobile phones are emerging which allow 
additional downloaded code to be installed in the phone. 
A concrete example is Java enabled mobile phone that 
can install new downloaded applets. This gives a ver- 
satile solution for adding new applications to the mobile 
phone. The user can select the applications that he 
needs and download them from a server. Examples of 
applications can be games, Calendar and meeting man- 
agement, e-commerce enabler applications etc. Some 
of these applications may need to interact with the se- 
curity token (SIM card or any other type of smart card 
or security token in the phone) in the mobile phone in 
order to benefit from its virtues as described above. This 
is especially important for downloaded applications that 
want to implement security related solutions and may 
need to access the smart card functions or store sensi- 
tive data in the card. Since downloaded code is not nec- 
essarily trusted the access to the smart card must be 
controlled and secure. Malicious applets may introduce 
security problems by using the smart card in a malicious 
way. Some of the possible attacks are described below: 

• Denial of service attacks (the Downloaded applica- 
tion can constantly send APDU commands to the 
SIM) 

• PIN code stealing (a malicious Downloaded appli- 



cation may capture the user's PIN code and send it 
over the network and/or authenticates itself as the 
user). If the Downloaded application is then able to 
use this PIN code and send it to the card it can man- 
5 age to do operations that normally can only be done 
upon user consent. An example is performing a 
non-repudiation digital signature with the smart 
card without user approval. 

• Gain read access to the user's private information 
10 on the card if a Downloaded application manages 

to get hold of the user's PIN code 

• Change data in the card if a Downloaded applica- 
tion manages to get hold of the user's PIN code 

15 [0004] This leads to a solution by which there is an 
access control to the smart card and also associated 
mechanisms that guarantee a controlled and secure in- 
teraction. 

20 What is already known? 

[0005] Mobile phones (or equivalent mobile appara- 
tus like PDAs) are emerging which allow the download- 
ing of new applications code in the phone. The interface 
25 between these apparatus and a smart card (or equiva- 
lent security token) in the phone is not defined today. 
This interface must give a solution that solves the 
threats that were expressed above. The aim of this in- 
vention is to provide such a solution. 

30 

What problem needs to be solved? 

[0006] This invention concerns a method for control- 
ling the access to the security token (e.g. smart card) in 

35 the phone or a communication apparatus. It should de- 
fine a controlled and secure access to the security token 
by which the newly downloaded applications can benefit 
from its functionality but at the same time cannot attack 
it or use it maliciously against the user or other parties 

40 that are involved in the application domain. 

How is the problem solved ? 

[0007] The solution relies on the existence of the fol- 
45 lowing identified roles in the mobile telecommunication 
arena: 

• Downloaded application provider (or service provid- 
er): These companies develop applications that can 

so then be downloadedto the mobile phone. They pro- 
vide value added services, useful applications and/ 
or games and entertainment in which the user may 
be interested. The user can download these appli- 
cations and install them in the phone. 

55 • Telecom operator: Provide the network infrastruc- 
ture for the communication and application down- 
load. The network operator is also the owner of the 
smart card (e.g. SIM card) in the phone and wants 
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to control the access to it by non-authorized parties 
(e.g. downloaded application code). 
• Phone manufacturer - Provide the phone and the 
integrated operating system that allows new appli- 
cation download. 

[0008] The identified roles suggest that access con- 
trol and usage of the security token in the phone (or oth- 
er communication apparatus) should be defined and im- 
plemented by the security token owner. In the case of a 
SIM card in GSM phones the security token owner is the 
Telecom operator, but in other business contexts it may 
be another entity, 

[0009] The invention concerns a method, implement- 
ed by several modules in the communication apparatus, 
by which the security token owner can, dynamically and 
also remotely, install security token a plurality of inter- 
faces (one or more) in the communication apparatus. 
These interfaces, and only these interfaces, can be 
used by the downloaded applications in order to access 
the security token. Also, downloaded applications can 
gain different security to ken interfaces depending on the 
credentials that they can present. 
[0010] A module called "Security Token Manager" is 
implemented in the communication apparatus (e.g. mo- 
bile phone) operating system in order to implement the 
proposed solution. This module controls the installation 
of new "Security Token Interfaces" in the communication 
apparatus. Security Token Interfaces are software mod- 
ules that implement access to the Security Token and 
expose a limited and high-level functions for the down- 
loaded applications in order to access the Security To- 
ken functionalities. Several Security Token Interfaces 
modules can be installed, each of which implement dif- 
ferent kind of interfaces for differentfunctionalities. Pref- 
erably, only the security token owner can install these 
Security Token Interfaces. The Security Token Manager 
installs the code for these interfaces only if it can verify 
that the Security Token Interfaces code is signed by the 
Security Token Owner. A digital signature using public 
key cryptography can be used for this purpose and the 
trusted certificate for verifying it may be retrieved from 
the Security Token itself. 

A downloaded application that needs to communicate 
with the Security Token (e.g. smart card) will ask the Se- 
curity Token Manager an interface object in order to 
communicate with the Security Token. The downloaded 
application will indicate the needed interface object 
name and then the Security Token Manager will need to 
check the downloaded application credentials in order 
to verify if it has the right to access this interface. The 
safest way to indicate a downloaded application creden- 
tials is to include it in its downloaded code with a digital 
signature that can be verified by the communication ap- 
paratus (e.g. mobile phone) operating system. The Se- 
curity Token Manager will retrieve the downloaded ap- 
plication credentials from the operating system and will 
then be able to deduce the access rights of the down- 
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loaded application. 

Figure 1 illustrates the relations between the different 
components in the described solution. 
[001 1 ] The described solution resolves the security is- 
5 sues that were expressed before in this document. An- 
other main advantage of this solution is the full control 
that the Security Token Owner has over the access in- 
terface which is accessible to downloaded applications. 
The Security Token Owner can remotely and dynami- 
se cally add Security Token Interfaces or remove some of 
them. This solution open the door to some interesting 
business models for deploying security related services 
with downloaded applications. 

15 Detailed Description of Examples Illustrating the 
Invention 

[0012] In order to simplify the description, the same 
elements illustrated in the drawings have the same ref- 
20 erences. 

[0013] Figure 1 represents an example of a data 
processing system S in which the invention may be ap- 
plied, 

[0014] Figure 2 illustrates a view of a communication 
25 apparatus including the following modules: a download- 
ed application, a security token manager and a security 
token interface. 

Figures 2 and 3 illustrates the interactions between the 
modules into the communication apparatus and be- 
30 tween the communication apparatus and the security to- 
ken. 

[0015] Figure 1 represents a system S. In our exam- 
ple, this system includes a smart card CAR coupled to 
a device ME communicating with a server SERV 

35 through a network RES. 

The following scenario aims to illustrate the interactions 
between a downloaded application DA in a mobile 
phone ME and the SIM smart card CAR in the phone. 
In this example, the SIM smart card has an application 

40 that manages cumulated loyalty points. 

Purpose 

[0016] This example illustrates the usage of the SIM 
45 card for providing a common secure portable data shar- 
ing media to several downloaded applications residing 
on the mobile device ME. 

Description 

50 

[0017] The user downloads and runs a variety of 
downloaded applications, games and online gaming or 
information services. As the downloaded applications 
DA are run the user gains points e.g. Loyalty points. In- 
55 stead of being stored within the downloaded applica- 
tions these points are stored on the SIM card CAR and 
then used as a common access pool to other download- 
ed applications. 
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Role of the card 

[0018] The card stores the users private loyalty points 
and can select if these points are used to upgrade for 
newer levels (an update of the downloaded application 
can then take place or a request can be sent to allow 
the SIM card CAR to authorize the next level) orfurther 
services. In addition, the points can be used to "pay" for 
additional network services such as ring-tones or addi- 
tional airtime in pre-paid. The advantage of being on the 
card is that a user could transferthem to another mobile 
phone, which could contain the same suite of download- 
ed applications. 

Implementation of the above scenario 

[0019] Several downloaded applications can share 
the same secure storage for loyalty points that is man- 
aged by a custom smart card application in the SIM card. 
A downloaded application that needs to update or read 
current loyalty points status as.ks the Security Token 
Manager STM for the Security Token Interface called 
"loyalty". 

The Security Token Manager STM will deliver this serv- 
ice object only if it can verify that the downloaded appli- 
cation DA is authorized to use it (e.g. has credentials 
with the right digital signature). The Security Token In- 
terface STI object was downloaded before by the Tele- 
com Operator or was retrieved directly from the smart 
card itself. In our example, the service provider that de- 
livers the downloaded application has an agreement 
with the telecom operator to use this interface. As a re- 
sultthe downloaded application DA knows how to inter- 
act the interface high level functions. 
[0020] In this example the "loyalty" Security Token In- 
terface object contains three functions: 

• VerifyUserldentity() 

• IncrementPoints(number) 

• DecrementPoints(number) 

[0021] In our example, when the downloaded appli- 
cation calls the VerifyUserldentity function the Security 
Token Interface object STI handles all the user interface 
interactions with the user in order to capture the user's 
PIN code and send it to the smart card application. The 
user's PIN code is not delivered to the downloaded ap- 
plication for security reasons. The Security Token Inter- 
face object also selects the needed smart card applica- 
tion and formats all APDU commands (low level smart 
card commands) that need to be sent. 
When the downloaded application DA calls the Incre- 
mentPoints orthe DecrementPoints functions the Secu- 
rity Token Interface object STI formats all the needed 
APDU commands that are needed to implement these 
functions, and send them to the smart card application. 



Claims 

1 . A method for controlling the access to a security to- 
ken (CAR) in a communication apparatus (ME) by 

5 downloaded applications (DA) accessing the secu- 
rity token, characterized in that it comprises the 
following steps: 

a. A service-accessing step in which a down- 
10 loaded application (DA) requests an access to 

the security token (CAR), 

b. A service-checking step in which a security 
token manager (STM), stored in the communi- 
cation apparatus, checks the corresponding 

15 rights, 

c. And in that, the communication apparatus 
storing a plurality of security token interfaces 
(STI), the Security Token Manager (STM)deliv- 
ers the demanded Security Token Interface 

20 (STI) to the application (DA) if rights are satis- 

fied or reject the demand . 

2. The method according to claim 1 , characterized in 
that the downloaded application (DA) is encrypted 

25 and/or signed, and in that for performing the serv- 
ice-checking step, the security token manager 
(STM) checks the corresponding rights by deter- 
mining credentials using the corresponding encryp- 
tion key orthe digital signature. 

30 

3. The method according to claim 1 , characterized in 
that each interface (STI) comprises high-level func- 
tions for the downloaded applications (DA) in order 
to access the Security Token (CAR) functionalities, 

35 and in that the interface (STI) formats all APDU 
commands (low level smart card commands) that 
need to be sent to the security token (CAR). 

4. The method according to claims 1 or 3, character- 
40 ized in that said interfaces (STI) are remotely in- 
stalled in the communication apparatus (ME) by the 
security token owner. 

5. The method according to claim 4, characterized in 
45 that the Security Token Manager (STM) installs the 

code for the interfaces in the communication appa- 
ratus (ME) only if it can verify thatthe Security Token 
Interfaces code is signed by the Security Token 
Owner. 

50 

6. The method according to claim 5, characterized in 
that a digital signature using public key cryptogra- 
phy is used and the trusted certificate for verifying 
it is retrieved from the Security Token (CAR) itself. 

55 

7. The method according to claim 1 , characterized in 
that, in step c), if the downloaded application (DA) 
has no rights no Security Token Interface (STI) ob- 
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